Proprietary token-based universal payment processing system

ABSTRACT

Embodiments described herein provide approaches for processing a payment in an electronic commerce environment. Specifically, a customer of a merchant website in the electronic commerce environment is provided a universal payment interface in response to the customer&#39;s request to pay. The universal payment interface retrieves a proprietary token from the customer. This proprietary token is a mobile device-based token that is provided by a provider associated with the mobile device. The universal payment interface requests a determination from the provider as to whether the proprietary token is valid, and the payment is verified based on the determination from the provider.

The present patent document is a continuation of U.S. patent applicationSer. No. 14/957,062, filed Dec. 3, 2015, entitled “PROPRIETARYTOKEN-BASED UNIVERSAL PAYMENT PROCESSING SYSTEM”, the disclosure ofwhich is incorporated herein by reference.

TECHNICAL FIELD

The subject matter of this invention relates generally to online paymentprocessing. More specifically, aspects of the present invention providean approach for utilizing a proprietary payment token as a universalpayment vehicle for processing a payment in an electronic commerceenvironment.

BACKGROUND

In the information technology environment of today, electronic commerceis becoming increasingly important. As more and more computer systemsand the connections between them increase in speed and throughput,increasingly more entities are offering their products through onlinechannels. This can provide greatly enhanced access to these products tocustomers and potential customers, resulting in a larger number ofavailable product offerings to consumers.

One important function of most any electronic commerce system is theability to process payments. In many conventional payment processingmethods, a card holder will be prompted to manually input paymentinformation (e.g., of a credit card). This often takes the form of auser (consumer) inputting various information (e.g., credit card number,expiration date, code, etc.) using an input device, such as a keyboard.

One challenge in electronic commerce payment processing is theprevention of payment information being used by unauthorized personnel(e.g., credit card fraud). This entails a combination of ensuring thatthe person using the payment information is the person authorized to doso and securing the information being sent so that the informationcannot be misappropriated during the transaction. One current solutionfor providing security includes entities providing a payment gateway forentry of payment information that has a Secure Socket Layer (SSL). SSLprovides a layer of encryption while the payment information is beingtransmitted for verification. Another current solution for providingsecurity includes providing verification through a third party verifier.

SUMMARY

In general, embodiments described herein provide approaches forprocessing a payment in an electronic commerce environment.Specifically, a customer of a merchant website in the electroniccommerce environment is provided a universal payment interface inresponse to the customer's request to pay. The universal paymentinterface retrieves a proprietary token from the customer. Thisproprietary token is a mobile device-based token that is provided by aprovider associated with the mobile device. The universal paymentinterface requests a determination from the provider as to whether theproprietary token is valid, and the payment is verified based on thedetermination from the provider.

One aspect of the present invention includes a computer-implementedmethod for processing a payment in an electronic commerce environment,the method comprising: providing a universal payment interface to acustomer of a merchant website in the electronic commerce environment inresponse to a request to pay by a customer; retrieving a proprietarytoken from the customer by the universal payment interface, theproprietary token being a mobile device-based token that is provided bya provider associated with a mobile device; requesting, by the universalpayment interface, a determination from the provider as to whether theproprietary token is valid; and verifying the payment based on thedetermination from the provider.

Another aspect of the present invention includes a computer system forprocessing a payment in an electronic commerce environment, the computersystem comprising: a memory medium comprising program instructions; abus coupled to the memory medium; and a processor for executing theprogram instructions, the instructions causing the system to: provide auniversal payment interface to a customer of a merchant website in theelectronic commerce environment in response to a request to pay by acustomer; retrieve a proprietary token from the customer by theuniversal payment interface, the proprietary token being a mobiledevice-based token that is provided by a provider associated with amobile device; request, by the universal payment interface, adetermination from the provider as to whether the proprietary token isvalid; and verify the payment based on the determination from theprovider.

Yet another aspect of the present invention includes a computer programproduct for processing a payment in an electronic commerce environment,the computer program product comprising a computer readable storagedevice, and program instructions stored on the computer readable storagedevice that, when executed, cause a computer device to: provide auniversal payment interface to a customer of a merchant website in theelectronic commerce environment in response to a request to pay by acustomer; retrieve a proprietary token from the customer by theuniversal payment interface, the proprietary token being a mobiledevice-based token that is provided by a provider associated with amobile device; request, by the universal payment interface, adetermination from the provider as to whether the proprietary token isvalid; and verify the payment based on the determination from theprovider.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of this invention will be more readilyunderstood from the following detailed description of the variousaspects of the invention taken in conjunction with the accompanyingdrawings in which:

FIG. 1 depicts a block diagram that illustrates a computerimplementation in which the invention may be implemented according toillustrative embodiments;

FIG. 2 depicts an example flow diagram according to an embodiment of thepresent invention;

FIG. 3 depicts a system diagram according to an embodiment of thepresent invention;

FIG. 4 depicts an example merchant web page according to illustrativeembodiments;

FIG. 5 depicts an example universal gateway proprietary token retrievalpage according to illustrative embodiments;

FIG. 6 depicts an example universal gateway proprietary token receiptpage according to illustrative embodiments;

FIG. 7 depicts an example universal gateway proprietary token receipterror page according to illustrative embodiments; and

FIG. 8 depicts a process flowchart according to illustrativeembodiments.

The drawings are not necessarily to scale. The drawings are merelyrepresentations, not intended to portray specific parameters of theinvention. The drawings are intended to depict only typical embodimentsof the invention, and therefore should not be considered as limiting inscope. In the drawings, like numbering represents like elements.

DETAILED DESCRIPTION

Illustrative embodiments will now be described more fully herein withreference to the accompanying drawings, in which illustrativeembodiments are shown. It will be appreciated that this disclosure maybe embodied in many different forms and should not be construed aslimited to the illustrative embodiments set forth herein. Rather, theseembodiments are provided so that this disclosure will be thorough andcomplete and will fully convey the scope of this disclosure to thoseskilled in the art.

Furthermore, the terminology used herein is for the purpose ofdescribing particular embodiments only and is not intended to belimiting of this disclosure. As used herein, the singular forms “a”,“an”, and “the” are intended to include the plural forms as well, unlessthe context clearly indicates otherwise. Furthermore, the use of theterms “a”, “an”, etc., do not denote a limitation of quantity, butrather denote the presence of at least one of the referenced items.Furthermore, similar elements in different figures may be assignedsimilar element numbers. It will be further understood that the terms“comprises” and/or “comprising”, or “includes” and/or “including”, whenused in this specification, specify the presence of stated features,regions, integers, steps, operations, elements, and/or components, butdo not preclude the presence or addition of one or more other features,regions, integers, steps, operations, elements, components, and/orgroups thereof.

Unless specifically stated otherwise, it may be appreciated that termssuch as “processing,” “detecting,” “determining,” “evaluating,”“receiving,” or the like, refer to the action and/or processes of acomputer or computing system, or similar electronic data center device,that manipulates and/or transforms data represented as physicalquantities (e.g., electronic) within the computing system's registersand/or memories into other data similarly represented as physicalquantities within the computing system's memories, registers or othersuch information storage, transmission, or viewing devices. Theembodiments are not limited in this context.

As stated above, embodiments described herein provide approaches forprocessing a payment in an electronic commerce environment.Specifically, a customer of a merchant website in the electroniccommerce environment is provided a universal payment interface inresponse to the customer's request to pay. The universal paymentinterface retrieves a proprietary token from the customer. Thisproprietary token is a mobile device-based token that is provided by aprovider associated with the mobile device. The universal paymentinterface requests a determination from the provider as to whether theproprietary token is valid, and the payment is verified based on thedetermination from the provider.

Referring now to FIG. 1, a computerized implementation 10 of anembodiment for processing a payment in an electronic commerceenvironment is shown. Computerized implementation 10 is only one exampleof a suitable implementation and is not intended to suggest anylimitation as to the scope of use or functionality of embodiments of theinvention described herein. Regardless, computerized implementation 10is capable of being implemented and/or performing any of thefunctionality set forth hereinabove.

In computerized implementation 10, there is a computer system 12, whichis operational with numerous other general purpose or special purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that may besuitable for use with computer system 12 include, but are not limitedto, personal computer systems, server computer systems, thin clients,thick clients, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputer systems, mainframe computersystems, and/or distributed cloud computing environments that includeany of the above systems or devices, and the like.

This is intended to demonstrate, among other things, that the presentinvention could be implemented within a network environment (e.g., theInternet, a wide area network (WAN), a local area network (LAN), avirtual private network (VPN), etc.), a cloud computing environment, acellular network, and/or on a stand-alone computer system. Communicationthroughout the network can occur via any combination of various types ofcommunication links. For example, the communication links can compriseaddressable connections that may utilize any combination of wired and/orwireless transmission methods. Where communications occur via theInternet, connectivity could be provided by conventional TCP/IPsockets-based protocol, and an Internet service provider could be usedto establish connectivity to the Internet. Still yet, computer system 12is intended to demonstrate that some or all of the components ofimplementation 10 could be deployed, managed, serviced, etc., by aservice provider who offers to implement, deploy, and/or perform thefunctions of the present invention for others.

Computer system 12 is intended to represent any type of computer systemthat may be implemented in deploying/realizing the teachings recitedherein. Computer system 12 may be described in the general context ofcomputer system executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and/orthe like, that perform particular tasks or implement particular abstractdata types. In this particular example, computer system 12 represents anillustrative system for processing a payment in an electronic commerceenvironment. It should be understood that any other computersimplemented under the present invention may have differentcomponents/software, but can perform similar functions.

Computer system 12 in computerized implementation 10 is shown in theform of a general-purpose computing device. The components of computersystem 12 may include, but are not limited to, one or more processors orprocessing units 16, a system memory 28, and a bus 18 that couplesvarious system components including system memory 28 to processing unit16.

Bus 18 represents one or more of any of several types of bus structures,including a memory bus or memory controller, a peripheral bus, anaccelerated graphics port, and/or a processor or local bus using any ofa variety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnects (PCI) bus.

Processing unit 16 refers, generally, to any apparatus that performslogic operations, computational tasks, control functions, etc. Aprocessor may include one or more subsystems, components, and/or otherprocessors. A processor will typically include various logic componentsthat operate using a clock signal to latch data, advance logic states,synchronize computations and logic operations, and/or provide othertiming functions. During operation, processing unit 16 collects androutes signals representing inputs and outputs between external devices14 and input devices (not shown). The signals can be transmitted over aLAN and/or a WAN (e.g., T1, T3, 56 kb, X.25), broadband connections(ISDN, Frame Relay, ATM), wireless links (802.11, Bluetooth, etc.), andso on. In some embodiments, the signals may be encrypted using, forexample, trusted key-pair encryption. Different systems may transmitinformation using different communication pathways, such as Ethernet orwireless networks, direct serial or parallel connections, USB,Firewire®, Bluetooth®, or other proprietary interfaces. (Firewire is aregistered trademark of Apple Computer, Inc. Bluetooth is a registeredtrademark of Bluetooth Special Interest Group (SIG)).

In general, processing unit 16 executes computer program code, such asfor processing a payment in an electronic commerce environment, which isstored in memory 28, storage system 34, and/or program/utility 40. Whileexecuting computer program code, processing unit 16 can read and/orwrite data to/from memory 28, storage system 34, and program/utility 40.

Computer system 12 typically includes a variety of computer systemreadable media. Such media may be any available media that is accessibleby computer system 12, and it includes both volatile and non-volatilemedia, removable and non-removable media.

System memory 28 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 30 and/or cachememory 32. Computer system 12 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia, (e.g., VCRs, DVRs, RAID arrays, USB hard drives, optical diskrecorders, flash storage devices, and/or any other data processing andstorage elements for storing and/or processing data). By way of exampleonly, storage system 34 can be provided for reading from and writing toa non-removable, non-volatile magnetic media (not shown and typicallycalled a “hard drive”). Although not shown, a magnetic disk drive forreading from and writing to a removable, non-volatile magnetic disk(e.g., a “floppy disk”), and an optical disk drive for reading from orwriting to a removable, non-volatile optical disk such as a CD-ROM,DVD-ROM, or other optical media can be provided. In such instances, eachcan be connected to bus 18 by one or more data media interfaces. As willbe further depicted and described below, memory 28 may include at leastone program product having a set (e.g., at least one) of program modulesthat are configured to carry out the functions of embodiments of theinvention.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium including, but not limited to, wireless,wireline, optical fiber cable, radio-frequency (RF), etc., or anysuitable combination of the foregoing.

Program/utility 40, having a set (at least one) of program modules 42,may be stored in memory 28 by way of example, and not limitation. Memory28 may also have an operating system, one or more application programs,other program modules, and program data. Each of the operating system,one or more application programs, other program modules, and programdata or some combination thereof, may include an implementation of anetworking environment. Program modules 42 generally carry out thefunctions and/or methodologies of embodiments of the invention asdescribed herein.

Computer system 12 may also communicate with one or more externaldevices 14 such as a keyboard, a pointing device, a display 24, etc.;one or more devices that enable a consumer to interact with computersystem 12; and/or any devices (e.g., network card, modem, etc.) thatenable computer system 12 to communicate with one or more othercomputing devices. Such communication can occur via I/O interfaces 22.Still yet, computer system 12 can communicate with one or more networkssuch as a local area network (LAN), a general wide area network (WAN),and/or a public network (e.g., the Internet) via network adapter 20. Asdepicted, network adapter 20 communicates with the other components ofcomputer system 12 via bus 18. It should be understood that although notshown, other hardware and/or software components could be used inconjunction with computer system 12. Examples include, but are notlimited to: microcode, device drivers, redundant processing units,external disk drive arrays, RAID systems, tape drives, and data archivalstorage systems, etc.

Referring now to FIG. 2, an example flow diagram 50 according to anembodiment of the present invention is shown. As illustrated, flowdiagram 50 shows an example flow among components in embodiments of thepresent invention.

Referring now to FIG. 3, a system diagram describing the functionalitydiscussed herein according to an embodiment of the present invention isshown. It is understood that the teachings recited herein may bepracticed within any type of networked computing environment 70 (e.g., acloud computing environment 50). A stand-alone computer system/server 12is shown in FIG. 1 for illustrative purposes only. In the event theteachings recited herein are practiced in a networked computingenvironment 70, each client computer 82 need not have a paymentprocessing engine (hereinafter “system 72”). Rather, all or part ofsystem 72 could be loaded on a server or server-capable device thatcommunicates (e.g., wirelessly) with the clients to provide deviceprotection therefor. This server or server-capable device could includea system of a merchant 74 in an electronic commerce environment, a tokenprovider system 78, and/or an independently administered system that isseparate from merchant website 74 and token provider system 78.Regardless, as depicted, system 72 is shown within computersystem/server 12. In general, system 72 can be implemented asprogram/utility 40 on computer system 12 of FIG. 1 and can enable thefunctions recited herein. It is further understood that system 72 may beincorporated within or work in conjunction with any type of system thatreceives, processes, and/or executes commands with respect to ITresources in a networked computing environment. Such other system(s)have not been shown in FIG. 3 for brevity purposes.

Along these lines, system 72 may perform multiple functions similar to ageneral-purpose computer. Specifically, among other functions, system 72can facilitate processing of payments in an electronic commerceenvironment. To accomplish this, system 72 can include: an interfaceprovider 90, a proprietary token retriever 92, a validity requestor 94,and a payment verifier 96.

Referring now to FIG. 4, an example merchant web page 100 is illustratedaccording to embodiments of the invention. Referring additionally toFIGS. 2 and 3, merchant web page 100 can be one of a plurality of pages76A-N on a merchant website 74 in an electronic commerce environment. Tothis extent, merchant web page 100 can be accessed by a user 80 throughnetworked computing environment 70 using a client computer 82. Clientcomputer 82 can include a personal computer (PC), laptop computer,tablet computer, terminal, and/or the like, running any operating systemnow known or later developed, including, but not limited to, MicrosoftWindows®, Apple®, Unix®-based system, etc. However, it should beunderstood that client computer 82 is a computer under the control ofcustomer 82 (e.g., belonging to customer 80, used by customer 80 in anemployment or similar capacity, and/or the like). To this extent, clientcomputer 82 should not be understood as including a credit card terminalor other computer device that is dedicated to or used by a merchant toprocess payment transactions at a point of sale. Further, it should beunderstood that client computer 82 is not meant to include the directaccess to merchant website 74 by a mobile device 84 and the direct useof mobile device 84 in to purchase goods and/or services in theelectronic commerce environment.

In any case, in an embodiment, customer 80 can access one or more pages76A-N on merchant website 74 using client computer 82, such as using aweb browser installed on client computer. In some cases customer 80 mayneed to provide user credentials (e.g., to log in using a username,password, and/or the like) in order to access merchant website 74, whilein other cases, no login may be required). In any case, customer 80 cannavigate through pages 76A-N on merchant website and can select A1 oneor more products that customer 80 wishes to purchase. Upon selecting A1,each of the products selected by customer 80 may be placed by merchantcite 74 into a shopping basket, which can aggregate the products thatcustomer 80 wishes to purchase until customer 80 has completed selectingA1 products for purchase. In an alternative embodiment, the selecting A1of the products can be performed by customer 80 via a voice-basedtelephonic connection. In this embodiment, customer 80 can provide theselection(s) A1 to a representative, which may be a human representativeor an automated interface.

In any case, once customer 80 has completed selecting A1 products forpurchase, customer 80 may indicate a readiness to submit payment for theselected items. In response to such an indication, the merchant website74 may cause a merchant payment page 102 to be displayed A2 to customer80 on client computer 80. As illustrated, merchant payment page 102 caninclude a summary 104 of the products that have been selected bycustomer 80, which may include a description of each of the products anda price associated with each of the products, among other things thathave not been illustrated for the sake of brevity, including, but notlimited to, tax, shipping, and/or the like. Further, merchant paymentpage 102 can include one or more payment options 110 from which customer80 can select for providing payment for the selected products. As shown,the payment options 110 provided by the particular merchant website 74having the merchant payment page 102 illustrated in FIG. 4 include threecredit cards 112. Further, payment options 110 include a third partyprocessor 114. Third party processor 114 is an independent dedicatedpayment site which allows customer 80 to store payment (e.g., creditcard) and to access the site for verification purposes. As also shown,payment options 110 include the use of a mobile device token 116, aswill be described in further detail herein. Alternatively, in the casethat the selecting Al of the products is performed by customer 80 via avoice-based telephonic connection, customer 80 can provide the selectionof the payment option to the same representative or a differentrepresentative, which may be a human representative or an automatedinterface.

The inventors of the invention described herein have discovered certaindeficiencies in current solutions for processing payments in anelectronic commerce environment. For example, if customer 80 chooses toselect payment by credit card 112, customer 80 conventionally isrequired to manually input his/her card information within a payment boxon an SSL payment page. Customer 80 would normally key in a credit cardnumber and other information into fields on the merchant payment page102 from a keyboard at the client computer 82. Similarly, if customer 80chooses to select payment by third party processor 114, customer 80would normally be required to key in or select credit card informationon the website of the third party processor 114. However, thesesolutions for entry/selection of credit card information can leave theinformation vulnerable to credit card fraud. For example, becausepossession of the physical card is not required, anyone who possessesthe card information can use the information to make purchases. Further,the information that is entered or selected using these solutions isvulnerable to theft during data entry (e.g., via a key logger program)or transfer (e.g., via a man-in-the-middle type attack) and used in afraudulent transaction. Further, these solutions require the use ofsecure sockets layer (SSL) type encryption, adding cost and complexityto the systems.

Referring again to FIGS. 1-3, interface provider 90 of system 72, asexecuted by computer system/server 12, is configured to provide A4 auniversal payment interface 60 to customer 80 of merchant website 74 inthe electronic commerce environment. The universal payment interface 60provided by interface provider 90 can be provided A4 in response to arequest to pay by customer 80.

For example, in an embodiment, interface provider 90 can provide a linkto the universal payment interface 60 on merchant website 74 (e.g., onmerchant payment page 102). As illustrated in FIG. 4, this link caninclude a mobile device token 116 option that can be selected bycustomer 80 from among a plurality of payment options 110 on merchantpayment page 102. Customer 80 would be redirected to a remote serverhaving universal payment interface 60 in response to a selection of thelink by customer 80.

In an alternative embodiment, universal payment interface 60 can beintegrated into merchant website 74. In this embodiment, universalpayment interface 60 may be the sole option provided to customer 80 forprocessing payment. In this case, universal payment interface 60 may beprovided directly to customer 80 by merchant website 74 in response tothe request to pay by customer 80. Alternatively, universal paymentinterface 60 may be one of a plurality of payment options 110 integratedinto merchant website 74 and available for selection by customer 80.

In an alternative embodiment, universal payment interface 60 can resideon client computer 82. In this embodiment, universal payment interface60 may be integrated into an application, such as a browser application;activated as a plugin to the browser application; or executed as astand-alone application on client computer 82. Whatever the case,universal payment interface 60 on client computer 82 can be provided tocustomer 80 in response to the request to pay by customer 80 that iscommunicated to the client computer.

In the alternative embodiment, in which the voice-based telephonicconnection is used, the same representative or a differentrepresentative, which may be a human representative or an automatedinterface, can provide customer 80 with a code in response to anindication that customer 80 is ready to pay. This provided code would beuniquely associated with the transaction that the user is performingover the voice-based telephonic connection in the electronic commerceenvironment. In this case, universal payment interface 60 may beprovided to customer 80 upon entry of the code by customer 80 into awebsite (e.g., a portion of merchant website 74 communicated to customer80 by the representative over the voice-based telephonic connection, orthe like) using client computer 82. To this extent, the code could beany combination of numeric or alphanumeric characters, symbols, or thelike, that can be entered onto a website using any solution now known orlater developed.

Referring again to FIGS. 1-3, proprietary token retriever 92 of system72, as executed by computer system/server 12, is configured to retrieveA8 a proprietary token 86 from customer 80 by the universal paymentinterface. Proprietary token 86 is a mobile device-based token that isprovided by a provider 66 associated with mobile device 84. Thisprovider 66 of proprietary token 86 can include a provider of thehardware of the mobile device 84, a provider of the operating system ofthe mobile device, a provider of a modification to the operating systemof the mobile device 84, and/or the like. To this extent, proprietarytoken 86 is typically tied to mobile device 84 such that proprietarytoken 86 has, to date, only been used in conjunction with mobile device84 (e.g., for purchases made on the mobile device 84 itself, forpurchases made by physically presenting the mobile device 84 at apayment terminal, or the like). Examples of such proprietary token 86include, but are not limited to, an Apple Pay® token (Apple Pay is aregistered trademark of Apple Computer, Inc.), a Samsung Pay® token(Samsung Pay is a registered trademark of Samsung, Inc.), a GoogleWallet® token (Goggle Wallet is a registered trademark of Google, Inc.),and/or the like).

In any case, proprietary token 86 is a package that includes paymentinformation (e.g., credit card information) of a user 80 of mobiledevice 84. This information is encrypted within proprietary token 86.Further, a different proprietary token 86 can be generated for eachpayment transaction by the provider, the mobile device 84, or acombination of the two. This allows the proprietary token 86 to beextremely secure, as the credit card information belonging to the user80 is never transmitted in clear text or found in clear text on themobile device 80. In an embodiment, proprietary token 86 can include aunique number that may have the same number of digits as the paymenttype (e.g., credit card, debit card, or similar financial bank carddata) that corresponds to the proprietary token 86. This unique numbercan be generated algorithmically, randomly, using encryption, or usingany solution now known or later developed. Further, this unique numbermay have the same final four numbers as the payment type from which theunique number was generated. Further, proprietary token 86 can alsoinclude additional elements including, but not limited to, an expirationdate, a credit verification value (CVV) code, biometric data, uniqueinformation related to the mobile device 84, or the like, which can beencrypted within a cryptogram, or the like. However, these examplesshould not be seen as limiting. Rather, proprietary token 86 can includeany payment information associated with a mobile device 84 that is nowknown or later developed, including, but not limited to, a payment tokenor an alternative number as representative of said payment token or atemporary replacement of a bank card number, or the like.

Referring now to FIG. 5, an example universal gateway proprietary tokenretrieval page 200 is shown according to illustrative embodiments. Asillustrated, universal gateway proprietary token retrieval page 200includes a summary 204 of the transaction being processed and a statusindicator 206 that indicates a status of the retrieval of proprietarytoken 86 from mobile device 84 via client computer 82. In an embodiment,universal gateway proprietary token retrieval page 200 can also includea set of token types 210 that the customer can select from.

Referring now to FIG. 5, in conjunction with FIGS. 2-4, proprietarytoken retriever 92 can initiate retrieval of proprietary token 86 bydownloading a retrieval request A5 to client computer 82. As shown, inFIG. 5, during retrieval request A5, status indicator 206 may display astatus of “Requesting Token” to customer 80. In an embodiment, retrievalrequest A5 can be initiated in response to a selection by customer 80 ofa token type 210 to be retrieved. Alternatively, retrieval request A5can be downloaded in response to a “ready” indication by customer 80 ordirectly in response to the providing of the universal paymentinterface. In such a case, the resulting proprietary token 86 can beanalyzed by the universal payment system to determine the provider ofthe proprietary token 86.

Whatever the case, retrieval request A5 downloaded to client computer 82from proprietary token retriever 92 causes the client computer toretrieve A7 proprietary token 86 from mobile device 84 of customer 80.To this extent, mobile device 84 can be a smartphone, a tablet, apersonal digital assistant (PDA), a smart watch, a personal musicdevice, a smart wristband, a smart free on board (fob), a smart sticker,smart clothing or any other computerized device now known or laterdeveloped that can have a proprietary token 86 associated therewith. Inany case, in an embodiment, the retrieval A7 of proprietary token 86 canbe performed via a physical (e.g., wired) connection between mobiledevice 84 and client computer 82. This physical connection can take theform of a universal serial bus (USB) cable, a Firewire connection, adocking station, direct serial or parallel connections, or any othersolution now known or later developed for facilitating a transfer ofinformation via a physical connection between a mobile device 84 to aclient computer 82.

Additionally or in the alternative, the retrieval A7 of proprietarytoken 86 can be performed over a distance via a wireless connectionbetween mobile device 84 and client computer 82. This wirelessconnection can be established directly in response to the receipt of theretrieval request A5 by client computer 82, or, alternatively, aninstruction for initiating the retrieval process can be transmitted tothe user 80. For example, the user 80 may be instructed to pass themobile device 84 over or within a certain proximity of client computer82. Subsequently, when client computer 82 detects the presence of mobiledevice 84 (e.g., via a video capture device, a signal strength detector,a motion detector, or the like), client computer 82 can establish A6 thewireless connection. In an embodiment, this wireless connection may usea Bluetooth® protocol (Bluetooth is a registered trademark of BluetoothSpecial Interest Group (SIG)). Alternatively, other remote connectionand/or wireless communications protocols can be utilized including, butnot limited to, infrared, wireless fidelity (Wi-Fi), near fieldcommunications (NFC), radio, microwave, short wave, cellular, satellite,and/or any other type of communications protocol that can be used toestablish A6 communications between client computer 82 and a mobiledevice 114.

In any case, once the client computer 82 has retrieved A7 proprietarytoken 86 from mobile device 84, the client computer 82 uploads A8 theretrieved proprietary token 86 to the universal payment interface. Asshown in FIG. 5, during this upload A8, status indicator 206 may displaya status of “Uploading”. This upload A8 can be performed using the samecommunications channel that customer 80 has previously been using tocommunicate with merchant website 74 or, alternatively, a secondaryand/or dedicated communication channel can be used. However, becauseproprietary token 86 is being used, and due to the security featuresinherent in a proprietary token 86, no further encryption or security isnecessary when performing the upload. To this extent, a customer's 80payment information can be provided without the need for creating a SSL,separate portal, or any other type of encryption/security.

Referring now to FIGS. 6 and 7, a pair of web pages 300 and 400illustrating possible responses to attempts by the universal paymentinterface to retrieve proprietary token 86 (FIG. 3) are illustratedaccording to embodiments of the invention. As illustrated, FIG. 6 showsa universal gateway proprietary token receipt page 300 (“receipt page”)that indicates that proprietary token 86 (FIG. 3) of customer 80 (FIG.3) has been retrieved A8 for processing payment. Receipt page 300 mayinclude a message 304 that alerts customer 80 that the token has beenreceived and provides any information that might be considered pertinentto the transaction. Conversely, FIG. 7 shows a universal proprietarytoken receipt error page 400, that indicates that the retrieval A8 ofproprietary token 86 (FIG. 3) of customer 80 (FIG. 3) was unsuccessful.Error page 400 can also include an error message 404 that indicates whythe token was not retrieved (e.g., process timeout, transmission error,unrecognizable token, etc.) and/or possible solutions for resolving theerror (e.g., moving mobile device 84 nearer to client computer 82, usinga different proprietary token 86, etc.). Further, error page 400 mayinclude tools to redirect customer 80 to alternative payment types inresponse to one or more failures.

Referring again to FIGS. 2 and 3, validity requestor 94 of system 72, asexecuted by computer system/server 12, is configured to request A9 adetermination from the provider (e.g., token provider system 78) as towhether the retrieved A8 proprietary token 86 is valid. For example, theretrieved A8 proprietary token 86 can be forwarded A9 by the universalpayment interface to token provider system 78, and is operated by theprovider of the proprietary token 86 to the mobile device 84. Thepropriety token 86 contains information that enables the provider toretrieve credit card information associated with customer 80. Forexample, in an embodiment (e.g., in which proprietary token 86 includesa unique number that is randomly generated or the like), token providersystem 78 may have a mapping table that is used to retrieve the originalcredit card number from the unique number in proprietary token 86.Further, provider system 78 has the encryption keys to decode anyinformation contained in a cryptogram, or the like. Thus, the providersystem 78 can read the information in the proprietary token 86 todetermine whether the proprietary token 86 is a valid proprietary token86 (e.g., not copied, counterfeit, etc.) and can send the credit cardinformation located in the proprietary token 86 to the servicer (e.g.,merchant processor, issuing bank, credit card company, etc.) forprocessing. Based on the information, the servicer can return anindication as to whether the transaction has been approved or whetherthe transaction has been denied.

Payment verifier 96 of system 72, as executed by computer system/server12, is configured to verify A11 the payment based on the determinationA10 from the provider (e.g., token provider system 78). For example, incases in which the proprietary token 86 was declined, an indication asto the reason (e.g., insufficient funds, unreadable proprietary token86, etc.) the proprietary token 86 was declined may be provided (e.g.,as an error code, message, etc.). Conversely, if the proprietary token86 was approved, the transaction is complete, and the products that werepurchased can be shipped or otherwise provided to customer 80. Theuniversal payment interface can provide an indication of thedetermination to the merchant website 74 and/or may redirect customer 80to the merchant website 74 at the completion of the transaction.

Referring now to FIG. 8 in conjunction with FIGS. 1-4, a methodflowchart 500 according to an embodiment of the present invention isshown. At S1, interface provider 90 of system 72, as executed bycomputer system/server 12, provides a universal payment interface to acustomer 80 of a merchant website 74 in the electronic commerceenvironment. This universal payment interface can be provided inresponse to a request to pay by the customer 80. At S2, proprietarytoken retriever 92 retrieves a proprietary token 86 from customer 80 bythe universal payment interface. At S3, validity requestor 94 requests adetermination from the provider of proprietary token 86 as to whetherthe proprietary token 86 is valid. This determination is requested bythe universal payment interface. At S4, payment verifier 96 of system72, as executed by computer system/server 12, verifies the payment basedon the determination from the provider.

Process flowchart 500 of FIG. 8 illustrates the architecture,functionality, and operation of possible implementations of systems,methods, and computer program products according to various embodimentsof the present invention. In this regard, each block in the flowchartmay represent a module, segment, or portion of code, which comprises oneor more executable instructions for implementing the specified logicalfunction(s). It should also be noted that, in some alternativeimplementations, the functions noted in the blocks might occur out ofthe order depicted in the figures. For example, two blocks shown insuccession may, in fact, be executed substantially concurrently. It willalso be noted that each block of flowchart illustration can beimplemented by special purpose hardware-based systems that perform thespecified functions or acts, or combinations of special purpose hardwareand computer instructions.

Some of the functional components described in this specification havebeen labeled as systems or units in order to more particularly emphasizetheir implementation independence. For example, a system or unit may beimplemented as a hardware circuit comprising custom VLSI circuits orgate arrays, off-the-shelf semiconductors such as logic chips,transistors, or other discrete components. A system or unit may also beimplemented in programmable hardware devices such as field programmablegate arrays, programmable array logic, programmable logic devices or thelike. A system or unit may also be implemented in software for executionby various types of processors. A system or unit or component ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions, which may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified system or unit need not be physicallylocated together, but may comprise disparate instructions stored indifferent locations which, when joined logically together, comprise thesystem or unit and achieve the stated purpose for the system or unit.

Further, a system or unit of executable code could be a singleinstruction, or many instructions, and may even be distributed overseveral different code segments, among different programs, and acrossseveral memory devices. Similarly, operational data may be identifiedand illustrated herein within modules, and may be embodied in anysuitable form and organized within any suitable type of data structure.The operational data may be collected as a single data set, or may bedistributed over different locations including over different storagedevices and disparate memory devices.

Furthermore, systems/units may also be implemented as a combination ofsoftware and one or more hardware devices. For instance, program/utility40 may be embodied in the combination of a software executable codestored on a memory medium (e.g., memory storage device). In a furtherexample, a system or unit may be the combination of a processor thatoperates on a set of operational data.

As noted above, some of the embodiments may be embodied in hardware. Thehardware may be referenced as a hardware element. In general, a hardwareelement may refer to any hardware structures arranged to perform certainoperations. In one embodiment, for example, the hardware elements mayinclude any analog or digital electrical or electronic elementsfabricated on a substrate. The fabrication may be performed usingsilicon-based integrated circuit (IC) techniques, such as complementarymetal oxide semiconductor (CMOS), bipolar, and bipolar CMOS (BiCMOS)techniques, for example. Examples of hardware elements may includeprocessors, microprocessors, circuits, circuit elements (e.g.,transistors, resistors, capacitors, inductors, and so forth), integratedcircuits, application specific integrated circuits (ASIC), programmablelogic devices (PLD), digital signal processors (DSP), field programmablegate array (FPGA), logic gates, registers, semiconductor devices, chips,microchips, chip sets, and so forth. However, the embodiments are notlimited in this context.

Any of the components provided herein can be deployed, managed,serviced, etc., by a service provider that offers to deploy or integratecomputing infrastructure with respect to a process for processing apayment in an electronic commerce environment. Thus, embodiments hereindisclose a process for supporting computer infrastructure, comprisingintegrating, hosting, maintaining, and deploying computer-readable codeinto a computing system (e.g., computer system 12), wherein the code incombination with the computing system is capable of performing thefunctions described herein.

In another embodiment, the invention provides a method that performs theprocess steps of the invention on a subscription, advertising, and/orfee basis. That is, a service provider, such as a Solution Integrator,can offer to create, maintain, support, etc., a process for processing apayment in an electronic commerce environment. In this case, the serviceprovider can create, maintain, support, etc., a computer infrastructurethat performs the process steps of the invention for one or morecustomers. In return, the service provider can receive payment from thecustomer(s) under a subscription and/or fee agreement, and/or theservice provider can receive payment from the sale of advertisingcontent to one or more third parties.

Also noted above, some embodiments may be embodied in software. Thesoftware may be referenced as a software element. In general, a softwareelement may refer to any software structures arranged to perform certainoperations. In one embodiment, for example, the software elements mayinclude program instructions and/or data adapted for execution by ahardware element, such as a processor. Program instructions may includean organized list of commands comprising words, values, or symbolsarranged in a predetermined syntax that, when executed, may cause aprocessor to perform a corresponding set of operations.

The present invention may also be a computer program product. Thecomputer program product may include a computer readable storage medium(or media) having computer readable program instructions thereon forcausing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network (i.e., the Internet, a local area network, a widearea network and/or a wireless network). The network may comprise coppertransmission cables, optical transmission fibers, wireless transmission,routers, firewalls, switches, gateway computers, and/or edge servers. Anetwork adapter card or network interface in each computing/processingdevice receives computer readable program instructions from the networkand forwards the computer readable program instructions for storage in acomputer readable storage medium within the respectivecomputing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus, or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

It is apparent that there has been provided herein approaches forprocessing a payment in an electronic commerce environment. While theinvention has been particularly shown and described in conjunction withexemplary embodiments, it will be appreciated that variations andmodifications will occur to those skilled in the art. Therefore, it isto be understood that the appended claims are intended to cover all suchmodifications and changes that fall within the true spirit of theinvention.

What is claimed is:
 1. A computer-implemented method for processing apayment in an electronic commerce environment, the method comprising:receiving, at a merchant payment interface from an internet browser on aclient computer used by a customer, a selection of a payment optionrequiring proprietary tokens on the merchant payment interface on afirst merchant website associated with a first merchant in theelectronic commerce environment in response to a request to pay by thecustomer; providing a universal payment interface to the internetbrowser of the client computer used by the customer of the firstmerchant website associated with a first merchant in the electroniccommerce environment in response to the selection of the payment optionrequiring proprietary tokens, the universal payment interface being athird-party interface on a separate server from the first merchantwebsite; receiving, from the internet browser on the client computerused by the customer, a second selection of a payment option requiring aproprietary token on the universal payment interface; downloading fromthe universal payment interface a retrieval request for the proprietarytoken corresponding to the payment option selected by the customer tothe internet browser of the client computer being used by the customerto access the first merchant website; establishing, by the internetbrowser of the client computer in response to a receipt of the retrievalrequest at the client computer, a wireless connection between the clientcomputer and a mobile device of the customer; forwarding, by theinternet browser of the client computer in response to the receipt ofthe establishing of the wireless connection, the retrieval request bythe client computer to the mobile device of the customer via thewireless connection; transferring, by the internet browser of the clientcomputer in response to a receipt of the retrieval request at the mobiledevice, the proprietary token stored on a mobile device of the customerfrom the mobile device to the client computer via the wirelessconnection, wherein the client computer and the mobile device are eachoperated separately from the separate server; transmitting, by theinternet browser of the client computer, the proprietary tokenelectronically over a network by the universal payment interface, theproprietary token being a mobile device-based token that is proprietaryto the mobile device and provided to the mobile device by a provider ofthe mobile device prior to the request to pay, the provider being atleast one of a manufacturer of a hardware of the mobile device or adeveloper of an operating system of the mobile device and beingindependent of the first merchant and the universal payment interface;requesting, by the universal payment interface in response to theretrieving of the proprietary token, a determination from the provideras to whether the proprietary token is valid; and verifying the paymentbased on the determination from the provider.
 2. The method of claim 1,further comprising: providing a link to the universal payment interfaceon the merchant website in the electronic commerce environment; andredirecting the customer to the universal payment interface in responseto a selection of the link by the customer.
 3. The method of claim 1,wherein the wireless connection uses at least one of a Bluetoothprotocol or Wi-Fi.
 4. The method of claim 1, wherein the propriety tokencontains information that enables the provider to retrieve credit cardinformation associated with the customer.
 5. The method of claim 1,wherein the propriety token is at least one of an Apple Pay token, aSamsung Pay token, or a Google Wallet token.
 6. The method of claim 1,further comprising: providing a code that is uniquely associated with atransaction in the electronic commerce environment to the customer via avoice-based telephonic connection; and redirecting the customer to theuniversal payment interface in response to an entry of the code into awebsite by the user.
 7. The method of claim 1, further comprising:providing the universal payment interface to a second customer of asecond merchant website associated with a second merchant that is notaffiliated with the first merchant in the electronic commerceenvironment in response to a request to pay by the second customer, thesecond merchant being independent of the provider and the universalpayment interface; retrieving a second proprietary token from the secondcustomer electronically over the network by the universal paymentinterface; requesting, by the universal payment interface in response tothe retrieving of the second proprietary token, a determination from theprovider as to whether the second proprietary token is valid; andverifying a second payment based on the determination from the provider.8. A computer system for processing a payment in an electronic commerceenvironment, the computer system comprising: a memory medium comprisingprogram instructions; a bus coupled to the memory medium; and aprocessor for executing the program instructions, the instructionscausing the system to: receive, at a merchant payment interface from aninternet browser on a client computer used by a customer, a selection ofa payment option requiring proprietary tokens on the merchant paymentinterface on a first merchant website associated with a first merchantin the electronic commerce environment in response to a request to payby the customer; provide a universal payment interface to the internetbrowser of the client computer used by the customer of the firstmerchant website associated with a first merchant in the electroniccommerce environment in response to the selection of the payment optionrequiring proprietary tokens, the universal payment interface being athird-party interface on a separate server from the first merchantwebsite; receive, from the internet browser on the client computer usedby the customer, a second selection of a payment option requiring aproprietary token on the universal payment interface; download from theuniversal payment interface a retrieval request for the proprietarytoken corresponding to the payment option selected by the customer tothe internet browser of the client computer being used by the customerto access the first merchant website; establish, by the internet browserof the client computer in response to a receipt of the retrieval requestat the client computer, a wireless connection between the clientcomputer and a mobile device of the customer; transfer, by the internetbrowser of the client computer in response to a receipt of the retrievalrequest at the mobile device, the proprietary token stored on a mobiledevice of the customer from the mobile device to the client computer viathe wireless connection, wherein the client computer and the mobiledevice are each operated separately from the separate server; transmit,by the internet browser of the client computer, the proprietary tokenelectronically over a network by the universal payment interface, theproprietary token being a mobile device-based token that is proprietaryto the mobile device and provided to the mobile device by a provider ofthe mobile device prior to the request to pay, the provider being atleast one of a manufacturer of a hardware of the mobile device or adeveloper of an operating system of the mobile device and beingindependent of the first merchant and the universal payment interface;request, by the universal payment interface in response to theretrieving of the proprietary token, a determination from the provideras to whether the proprietary token is valid; and verify the paymentbased on the determination from the provider.
 9. The computer system ofclaim 8, the instructions further causing the system to: provide a linkto the universal payment interface on the merchant website in theelectronic commerce environment; and redirect the customer to theuniversal payment interface in response to a selection of the link bythe customer.
 10. The computer system of claim 8, wherein the wirelessconnection uses at least one of a Bluetooth protocol or Wi-Fi.
 11. Thecomputer system of claim 8, wherein the propriety token containsinformation that enables the provider to retrieve credit cardinformation associated with the customer.
 12. The computer system ofclaim 8, wherein the propriety token is at least one of an Apple Paytoken, a Samsung Pay token, or a Google Wallet token.
 13. The system ofclaim 8, the instructions further causing the system to: provide a codethat is uniquely associated with a transaction in the electroniccommerce environment to the customer via a voice-based telephonicconnection; and redirect the customer to the universal payment interfacein response to an entry of the code into a website by the customer. 14.The system of claim 8, the instructions further causing the system to:provide the universal payment interface to a second customer of a secondmerchant website associated with a second merchant that is notaffiliated with the first merchant in the electronic commerceenvironment in response to a request to pay by the a second customer,the second merchant being independent of the provider and the universalpayment interface; retrieve a second proprietary token from the secondcustomer electronically over the network by the universal paymentinterface; request, by the universal payment interface in response tothe retrieving of the second proprietary token, a determination from theprovider as to whether the second proprietary token is valid; and verifya second payment based on the determination from the provider.
 15. Acomputer readable storage device having a computer program product forprocessing a payment in an electronic commerce environment storedthereon, the computer program product comprising program instructionsstored on the computer readable storage device that, when executed,cause a computer device to: receive, at a merchant payment interfacefrom an internet browser on a client computer used by a customer, aselection of a payment option requiring proprietary tokens on themerchant payment interface on a first merchant website associated with afirst merchant in the electronic commerce environment in response to arequest to pay by the customer; provide a universal payment interface tothe internet browser of the client computer used by the customer of thefirst merchant website associated with a first merchant in theelectronic commerce environment in response to the selection of thepayment option requiring proprietary tokens, the universal paymentinterface being a third-party interface on a separate server from thefirst merchant website; receive, from the internet browser on the clientcomputer used by the customer, a second selection of a payment optionrequiring a proprietary token on the universal payment interface;download from the universal payment interface a retrieval request forthe proprietary token corresponding to the payment option selected bythe customer to the internet browser of the client computer being usedby the customer to access the first merchant website; establish, by theinternet browser of the client computer in response to a receipt of theretrieval request at the client computer, a wireless connection betweenthe client computer and a mobile device of the customer; transfer, bythe internet browser of the client computer in response to a receipt ofthe retrieval request at the mobile device, the proprietary token storedon a mobile device of the customer from the mobile device to the clientcomputer via the wireless connection, wherein the client computer andthe mobile device are each operated separately from the separate server;transmit, by the internet browser of the client computer, theproprietary token electronically over a network by the universal paymentinterface, the proprietary token being a mobile device-based token thatis proprietary to the mobile device and provided to the mobile device bya provider of the mobile device prior to the request to pay, theprovider being at least one of a manufacturer of a hardware of themobile device or a developer of an operating system of the mobile deviceand being independent of the first merchant and the universal paymentinterface; request, by the universal payment interface, a determinationfrom the provider as to whether the proprietary token is valid; andverify the payment based on the determination from the provider.
 16. Thecomputer program product of claim 15, the program instructions furthercausing the computer device to: provide a link to the universal paymentinterface on the merchant website in the electronic commerceenvironment; and redirect the customer to the universal paymentinterface in response to a selection of the link by the customer. 17.The computer program product of claim 15, wherein the wirelessconnection uses at least one of a Bluetooth protocol or Wi-Fi.
 18. Thecomputer program product of claim 15, wherein the propriety tokencontains information that enables the provider to retrieve credit cardinformation associated with the customer.
 19. The computer programproduct of claim 15, wherein the propriety token is at least one of anApple Pay token, a Samsung Pay token, or a Google Wallet token.
 20. Thecomputer program product of claim 15, the program instructions furthercausing the computer device to: provide a code that is uniquelyassociated with a transaction in the electronic commerce environment tothe customer via a voice-based telephonic connection; and redirect thecustomer to the universal payment interface in response to an entry ofthe code into a website by the user.
 21. The computer program product ofclaim 15, the program instructions further causing the computer deviceto: provide the universal payment interface to a second customer of asecond merchant website associated with a second merchant that is notaffiliated with the first merchant in the electronic commerceenvironment in response to a request to pay by the second customer, thesecond merchant being independent of the provider and the universalpayment interface; retrieve a second proprietary token from the secondcustomer electronically over the network by the universal paymentinterface; request, by the universal payment interface in response tothe retrieving of the second proprietary token, a determination from theprovider as to whether the second proprietary token is valid; and verifya second payment based on the determination from the provider.